Ir al contenido

ARINC 653

De Wikipedia, la enciclopedia libre

ARINC 653 (Avionics Application Standard Software Interface) es una especificación software para el particionado de tiempo y espacio en sistemas operativos de tiempo real críticos para aviónica. Permite la ejecución de varios aplicaciones en diferentes niveles software en un hardware común en el contexto de arquitecturas de aviónica integrada modular. Esta especificación es parte de la serie ARINC 600.

Visión general

[editar]

Con el fin de desacoplar la plataforma del sistema operativo en tiempo real de la aplicación Software, ARINC 653 define una API denominada APEX (APplication EXecutive).

Cada aplicación software se denomina partición y contiene su propio espacio de memoria aislado. Cada partición tiene, además, un espacio de tiempo asignado por la API APEX. Dentro de cada partición, se permite la ejecución de varias tareas. APEX provee servicios para el manejo de particiones, procesos y tiempo, así como rutinas para manejar de errores y servicios de comunicación entre particiones y procesos. Aunque no es un requisito, el entorno de participando se puede implementar mediante un hipervisor, para asignar particiones a máquinas virtuales o contenedores.

Actualmente, el subcomité AEEC APEX trabaja en incluir mejoras para el soporte de arquitecturas multi procesador en ARINC 653.

Historia

[editar]

Versión Inicial

[editar]

La primera versión de ARINC 653 se publicó el 10 de octubre de 1996.

ARINC 653-1

[editar]

La primera revisión del estándar se publicó en enero de 1997, introduciendo el concepto de APEX y el participando de tiempo y espacio.

ARINC 653-2

[editar]

La segunda revisión del estándar consta de tres partes que se publicaron entre marzo de 2006 y enero de 2007.[1]

  • La primera parte (servicios indispensables) define el manejo de particiones, así como los conceptos de arranque en frío y arranque en caliente. Además introduce las funcionalidades de manejo de errores en software y las APIs en Ada y C.
  • La segunda parte (servicios opcionales), define los requisitos para el acceso a sistema de archivos, registro de datos y puntos de acceso entre otros.
  • Por último, la tercera parte especifica las pruebas que debe pasar un sistema para ser certificado para ARINC 653.

Organización actual del Estándar

[editar]
  • Parte 0 - Introducción a ARINC 653 (primera revisión en junio de 2013)[2]
  • Parte 1: Servicios Indispensables (cuarta revisión en agosto de 2015)[3]
  • Parte 2: Servicios Adicionales (tercera revisión en agosto de 2015)[4]
  • Parte 3: Pruebas de Conformidad (primera revisión el 16 de octubre de 2006)[5]
  • Parte 4: Subconjunto de Servicios (primera revisión en junio de 2012)[6]
  • Parte 5: Características recomendadas para el núcleo software. (primera revisión en diciembre de 2014)[7]

Principios básicos del particionado

[editar]

Una plataforma ARINC 653 contiene:

Inicialización

[editar]

En la rutina de inicialización de una partición en ARINC 653 se crean los recursos necesarios por la partición, como por ejemplo tareas (PROCESS), eventos (EVENT) y semáforos (SEMAPHORE) entre otros. Cada uno de estos recursos se crean mediante llamadas a la API con nombre CREATE_xxxx, por ejemplo, CREATE_PROCESS.

Manejo de Errores

[editar]

El manejo de errores y excepciones en una partición se realiza de forma apropiativa mediante un proceso que tiene asignada la máxima prioridad. Este proceso se crea en la etapa de inicialización de la partición mediante el servicio de la API CREATE_ERROR_HANDLER.

La API permite al proceso de manejo de errores detener la ejecución de un proceso que ha fallado mediante el servicio STOP_SELF. En este caso, el planificador del sistema operativo de tiempo real comienza a ejecutar el siguiente proceso con mayor prioridad.

El estándar ARINC 653 no especifica qué debe hacer el planificador si el proceso de manejo de errores no detiene la ejecución del proceso que ha fallado. En algunos casos (teóricos), esto puede dar lugar a un bucle infinito entre la aplicación que esta fallando y el proceso de manejo de errores.

El proceso de manejo de errores puede obtener información sobre la fuente y el contexto del error o excepción.

Administración de modo

[editar]

Cada partición puede estar en varios estados:

  • COLD_START y WARM_START: Sólo el proceso de inicialización está en ejecución.
  • NORMAL: El proceso de inicialización ha terminado, y los otros procesos de la partición se ejecutan por el planificador en función de su prioridad,
  • IDLE: Ningún proceso se está ejecutando. Aun así, en teoría, algún proceso con la prioridad más baja podría comenzar a ejecutarse, por ejemplo un proceso que inicia un bucle infinito.

El servicio SET_PARTITION_MODE de la API permite seleccionar estos estados. Puede ser llamado por cualquier proceso en la partición. La entrada en modo IDLE es irreversible y solo un evento externo (por ejemplo el reinicio del sistema) puede cambiar este estado.

Procesos de una partición

[editar]

Cada partición tiene al menos un proceso. La planificación de procesos es apropiativo. El planificador se llama mediante un temporizador, o mediante la API.

APEX, API de ARINC 653

[editar]

La API de ARINC 653, APEX, contiene funcionalidades clasificadas en seis categorías:

  • Administración de particiones
  • Administración de procesos
  • Administración de participando de tiempo
  • Comunicación entre particiones
  • Comunicación dentro de una misma partición
  • Manejo de errores

APEX no define APIs para la administración de memoria, por lo tanto, cada partición debe manejar su propia memoria (aunque cumpliendo con las limitaciones de participando de memoria requeridos por ARINC 653).

Cada servicio de la API devuelve uno de los códigos de error que se definen a continuación para indicar si la llamada al servicio ha sido exitosa o se ha producido algún fallo.

  • NO_ERROR: no se ha producido ningún error
  • NO_ACTION: el estado del sistema no ha cambiado después de ejecutar el servicio
  • NOT_AVAILABLE: el servicio no se encuentra disponible
  • INVALID_PARAM: al menos uno de los parámetros del servicio es no es válido
  • INVALID_CONFIG: al menos uno de los parámetros del servicio es incompatibles con la configuración actual del sistema
  • INVALID_MODE: el servicio es incompatible con el modo actual del sistema
  • TIMED_OUT: se ha alcanzado el tiempo límite de ejecución del servicio

Enlaces a POSIX y ASAAC

[editar]

El dominio cubierto por ARINC 653 y ASAAC Def Stan 00-74 son similares. Aun así, hay diferencias entre los dos estándares.[8]

Algunas APIs de APEX tienen equivalentes POSIX, pero su definición puede diferir de la descrita en POSIX.[8]

Por ejemplo, la siguiente llamada definida en ASAAC:

 receiveBuffer

Sería equivalente a la de esta función APEX:

 RECEIVE_BUFFER()

Y también sería equivalente en POSIX a:

 recv()

Véase también

[editar]

Referencias

[editar]
  1. «Product Focus: ARINC 653 and RTOS». aviationtoday.com. 1 de julio de 2004. Archivado desde el original el 3 de diciembre de 2009. Consultado el 30 de mayo de 2009. 
  2. «Avionics Application Software Standard Interface: ARINC Specification 653 Part 0». Aeronautical Radio, Inc. June 2013. Archivado desde el original el 20 de noviembre de 2013. 
  3. «Avionics Application Software Standard Interface: ARINC Specification 653P1-3, Required Services». Aeronautical Radio, Inc. 15 de noviembre de 2010. Archivado desde el original el 10 de mayo de 2012. Consultado el 20 de octubre de 2013. 
  4. «Avionics Application Software Standard Interface: ARINC Specification 653P2-2, Part 2, Extended Services». Aeronautical Radio, Inc. 1 de junio de 2012. Archivado desde el original el 25 de agosto de 2012. Consultado el 20 de octubre de 2012. 
  5. «Avionics Application Software Standard Interface: ARINC Specification 653P3, Conformity Test Specification». Aeronautical Radio, Inc. 20 de octubre de 2006. Archivado desde el original el 10 de mayo de 2012. Consultado el 20 de noviembre de 2013. 
  6. «Avionics Application Software Standard Interface: ARINC Specification 653 Part 4, Subset Services». Aeronautical Radio, Inc. 1 de junio de 2012. Archivado desde el original el 25 de agosto de 2012. Consultado el 20 de octubre de 2013. 
  7. «ARINC Store». ARINC IA. 1 de diciembre de 2014. Consultado el 23 de abril de 2015. 
  8. a b «Flexibility and Manageability of IMS Projects». University of York. Consultado el 27 de julio de 2008.